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I.  INTRODUCTION 


A.  SCOPE 

Although  Information  Assurance  (IA)  is  important  to  the  mission  and  IA  policy 
provides  the  foundation  for  maintaining  a  secure  posture,  the  process  of  updating, 
disseminating,  and  maintaining  current  IA  policy  remains  a  problem  in  the  Department  of 
Defense  (DoD).  As  upper-level  policies  are  changed  and  updated,  the  lower-level  policies 
that  reference  them  must  also  be  updated  to  comply  with  the  changes.  Often  those  who 
are  responsible  for  maintaining  those  lower-level  policies  are  unaware  of  the  upper-level 
policy  changes,  so  inconsistency  ensues.  In  addition,  those  who  use  the  policies  must 
research  multiple  DoD  websites  and  often  struggle  with  detennining  the  correct  version 
of  the  most  current  policies,  particularly  when  inconsistencies  are  discovered.  With  all  of 
the  available  sources  of  this  infonnation,  policy  updates  must  be  de-conflicted.  This 
research  will  be  bounded  at  the  upper  level  by  the  Department  of  the  Navy  (DON)  and  at 
the  lower  level  by  the  local  policies  at  the  Naval  Postgraduate  School  (NPS).  Once  the 
taxonomy  is  utilized  for  this  subset  of  DoD  policies,  this  thesis  will  discuss  the  portability 
of  this  model  to  include  the  DoD  as  the  new  upper-bound. 

B.  CURRENT  POLICY  DISSEMINATION  PRACTICES 

The  links  between  lower-level  policies  and  the  upper-level  policies  they  reference 
must  correspond  to  the  correct  versions  of  the  upper-level  policies.  As  part  of  this  thesis, 
there  will  be  a  review  of  the  current  manual  processes  for  disseminating  policy  changes 
and  how  users  of  policies  manually  detennine  the  most  current  versions  of  upper-level 
policies.  This  thesis  will  develop  the  methodology  to  automate  the  dissemination  of 
policy  changes.  The  process  also  will  consider  the  requirement  to  “archive”  policy 
versions  that  may  be  referenced  in  DON  contracts. 
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c. 


RESEARCH  GOALS 


1.  Taxonomy 

This  research  carries  multiple  goals,  which  will  be  addressed  in  sections.  The  first 
goal  is  to  develop  a  taxonomy  of  IA  policies  in  the  DON.  The  upper-bound  of  this 
taxonomy  will  be  the  IA  policies  found  on  the  Department  of  the  Navy  Chief  Information 
Officer  website  and  related  websites  that  house  DON-level  policies  with  the  assumption 
that  all  updates  and  changes  to  policies  above  this  level  are  correctly  implemented.  The 
lower-bound  for  this  taxonomy  will  be  the  “local”  level  as  represented  by  the  IA  policies 
at  the  NPS  level.  The  taxonomy  will  describe  the  links  from  policies  in  the  upper-bound 
to  policies  in  the  lower-bound,  as  well  as  links  between  policies  residing  at  the  same 
level.  Mapping  this  relationship  between  policies  is  the  first  step  to  establishing  a  means 
of  automatically  conveying  policy  changes  in  a  timely  and  efficient  manner. 

2.  Automatic  Conveyance  of  Policy  Changes 

The  next  goal  of  this  research  is  to  find  a  way  to  automatically  convey  when  there 
have  been  changes  to  upper-level  policies  if  there  are  lower-level  policies  that  are 
potentially  affected  by  the  change.  If  possible,  the  changes  themselves  should  be  included 
in  the  information  that  is  passed  along  to  convey  the  change,  and  the  administrator  in 
charge  of  reviewing  the  policies  should  know  specifically  which  lower-level  policies  are 
affected  by  the  change.  This  makes  the  job  of  detennining  which  policies  need  to  be 
reviewed  simple  and  efficient. 

3.  Policy  Versioning 

The  third  goal  of  this  research  is  to  maintain  versions  of  policies  that  can  be 

referenced  if  necessary.  The  space  that  is  used  to  house  the  most  current  and  up-to-date 

policies  should  also  house  the  older  versions  of  those  policies  in  order  to  make  them 

easier  to  find.  This  must  be  done  in  such  a  way  as  to  clearly  show  which  versions  are 

current  and  which  are  out  of  date  without  taking  away  accessibility  to  older  versions  as 

they  are  needed.  The  outdated  versions  should  always  be  read-only  in  order  to  preserve 

them  in  case  it  becomes  necessary  to  roll  back  to  them  or  if  a  contract  is  based  on  older 
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policies  that  have  since  been  replaced  or  updated.  As  it  stands  now,  these  versions  can  be 
difficult  to  find  and  their  dates  of  use  may  be  incomplete  or  unclear. 

This  research  will  attempt  to  disambiguate  policy  versions  and  dates  of  use,  as 
well  as  make  it  easy  to  keep  policies  up-to-date  without  needing  extensive  research. 
Policies  should  have  default  review  deadlines  regardless  of  whether  changes  have 
occurred  in  referenced  upper-level  policies  to  ensure  administrator  users  remain  aware  of 
current  versions  and  make  updates  as  necessary  for  operating  purposes.  When  changes 
have  been  made,  the  changes  should  be  distinguished  by  whether  they  are  major  content 
changes  or  minor  grammatical  changes,  and  there  should  be  due  dates  for  those  changes 
to  be  pushed  down.  For  example,  small  grammatical  changes  that  do  not  affect  content  or 
meaning  should  be  approved  immediately  without  going  through  a  chain  of  approval.  On 
the  other  hand,  content  changes  should  be  reviewed  and  approved  on  a  minimum  set 
schedule  with  bigger  or  more  important  changes  implemented  on  a  timely  basis  as  the 
administrator  sees  fit.  This  could  mean  that  content  changes  must  be  rolled  out  to  lower- 
level  policies  at  a  minimum  of  once  a  year,  or  more  often  as  needed.  This  would  ensure 
that  lower-level  policies  would  not  become  years  out  of  date,  losing  their  relevance  and 
effectiveness. 

4.  Proof  of  Concept  (Implementation) 

The  fourth  goal  of  this  research  is  to  build  a  proof  of  concept  that  demonstrates 
that  the  taxonomy  is  an  effective  structure  for  linking  policies  that  reference  one  another 
so  that  the  changes  to  upper-level  policies  are  conveyed  accurately  to  the  administrator  of 
lower-level  policies  that  refer  to  them.  A  way  of  doing  this  is  to  set  the  administrator  in 
charge  of  lower-level  policies  as  a  “watcher”  of  the  upper-level  policies  they  reference, 
and  when  changes  occur,  the  administrator  is  notified.  If  related  policies  are  grouped  by 
code  to  indicate  the  links  between  them,  this  would  ensure  that  the  administrator  knows 
which  policies  to  review  without  having  to  trace  back  the  relationships  between  policies 
from  the  references  section  of  each  policy.  The  proof  of  concept  as  described  here  entails 
a  lot  of  front-end  work  to  get  the  policies  into  a  collaborative  wiki  format,  but  once  it  is 
in  place  and  organized  according  to  the  taxonomy,  it  will  require  little  maintenance  to 
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keep  policies  up  to  date  and  accessible.  The  ideal  results  will  be  achieved  if  there  is  a 
DON-wide  compatible  wiki  format  to  house  IA  policies.  Failing  this,  an  administrator 
could  simply  keep  a  list  of  the  upper-level  policies  and  stay  on  RSS  [Rich  Site  Summary] 
feeds  or  email  lists  to  receive  notification  of  changes  to  policies  in  the  DON-level.  Once 
changes  have  been  made  to  policies  at  this  level,  the  administrator  will  upload  the 
changes  to  the  wiki  and  the  group  notifications  for  affected  policies  will  appear.  This  will 
also  continue  to  provide  policy  versioning  since  the  relevant  policies  and  their  versions 
will  be  stored  and  accessible  on  the  wiki,  which  in  the  case  of  this  research  is  housed  on 
the  local  education  network. 

D.  POLICY  MAINTENANCE 

This  research  will  accomplish  several  things  that  are  currently  lacking  in  many 
government  agencies  at  the  local-level.  Too  often,  the  maintenance  of  current  policies 
takes  a  back  seat  to  all  of  the  other  important  tasks  and  functions  within  an  agency.  Once 
policy  maintenance  begins  to  slip,  it  can  get  out  of  hand  quickly  and  local  policies  may 
become  years  out-of-date  before  they  are  noticed.  This  neglect  cannot  be  allowed  to 
happen  in  an  environment  where  policy  is  the  foundation  of  day-to-day  cybersecurity 
operations.  This  style  of  updating  spreads  the  responsibility  and  knowledge  of  policy 
updates  to  more  people.  In  many  agencies,  there  is  a  “policy  person”  who  is  responsible 
for  keeping  local  policy  information  up-to-date  and  who  knows  where  to  look  for  all 
pertinent  information.  This  is  a  job  that  takes  practice  and  extensive  background 
knowledge,  and  is  usually  the  responsibility  of  a  particular  person.  This  violates  the 
practice  of  separation  of  duties  that  is  described  as,  “A  security  principle  that  splits  up  a 
critical  task  among  two  or  more  individuals  to  ensure  that  one  person  cannot  complete  a 
risky  task  by  himself  [1].”  While  policy  maintenance  is  not  generally  considered  a  risky 
task  in  and  of  itself,  it  is  important  to  remember  that  the  neglect  of  policy  maintenance 
may  become  a  liability  when  current  policies  are  difficult  to  find  in  a  timely  manner,  or  if 
policies  go  out-of-date  and  the  person  responsible  for  this  job  is  unavailable  to  address 
the  problem. 
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With  the  infrastructure  from  this  thesis  in  place,  the  process  of  updating  policies 
will  be  accessible  to  anyone  with  administrator  privileges  to  the  wiki  and  policies  will  be 
easily  maintained  in  the  event  that  the  policy  manager  is  made  unavailable  to  perform  the 
duties  of  the  job.  The  end  goal  of  this  research  is  to  make  IA  policies  maintainable  no 
matter  the  staffing  circumstances,  and  this  infrastructure  provides  the  means  to  revise  the 
currently  complicated  role  of  policy  maintenance. 
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II.  BACKGROUND  AND  RESEARCH 


A.  DIRECTION  OF  INFORMATION  FFOW 

This  thesis  presents  a  proposed  answer  to  the  question  of  how  to  create  and 
implement  a  taxonomy  of  security  policies  in  a  semantic  wiki  in  order  to  enable 
automated  conveyance  of  updates  from  higher-level  policies  to  lower-level  policies.  This 
can  also  be  applied  between  policies  at  the  same  level  with  the  exception  of  policies  at 
the  top  level  since  information  does  not  flow  between  them.  The  information  flow  in  this 
model  is  from  top  to  bottom,  or  between  lower-level  policies  at  the  same  level,  and 
follows  step-wise  flow  of  information  similar  to  that  found  in  existing  infonnation 
processing  flowcharts  [2].  The  concept  of  using  hierarchies  for  decision  making  and 
showing  the  flow  of  information  in  a  system  is  not  a  new  one.  There  has  been  a  vast 
amount  of  research  applying  hierarchical  models  to  everything  from  marketing  decisions 
to  diagnosis  [3]  -  [7].  The  only  new  information  this  research  brings  is  how  to  effectively 
apply  this  knowledge  to  the  problem  of  information  flow  between  policies  at  different 
levels  within  the  DON.  This  introduces  two  challenges:  1)  how  to  create  the  right 
taxonomy  to  portray  the  relationships  between  policies,  and  2)  how  to  implement  that 
taxonomy  within  the  semantic  wiki  so  the  information  flows  in  the  right  direction. 

B.  WIKI  COFFABORATION  WITHIN  THE  GOVERNMENT 

The  wiki  format  has  been  successfully  used  within  the  government  for 
collaboration  on  classified  data.  Intellipedia  was  created  in  2005  and  unveiled  in  2006 
[8],  [9].  It  has  three  levels  that  correspond  to  top  secret,  secret,  and  unclassified  data  that 
can  be  shared  with  users  authenticated  to  each  level.  While  the  primary  use  of  Intellipedia 
is  collaboration  on  data  of  different  classifications  to  allow  for  quick  decision-making 
and  dissemination  of  time-sensitive  information,  wiki  technology  also  can  be  used  to 
keep  policies  up-to-date.  The  functionality  that  a  wiki  provides  is  useful  for  conveying 
updates  of  upper-level  policies  to  the  lower-level  policies  that  reference  them.  The  fact 
that  the  government  recognizes  the  necessity  to  migrate  to  more  online  collaborative 
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environments  is  a  good  indicator  that  it  is  time  to  think  about  how  this  impacts  the  world 
of  IA  policy  [10].  This  so-called  e-govemment  is  recognized  as  an  important  tool  for 
collaboration  and  user  participation  [11],  [12],  If  wiki  technology  is  utilized  early  in  the 
IA  policy  process,  this  will  ensure  that  cybersecurity  technologies  do  not  outpace  the  IA 
policies  that  govern  their  use. 

Increasingly,  support  has  been  shown  for  the  implementation  of  wiki  technology 
for  collaboration  and  dissemination  of  information  within  the  government  [13].  The 
potential  for  collaborative  work  is  undeniable,  and  in  light  of  this,  the  movement  of 
government  to  wiki  technology  seems  inevitable.  The  advantages  of  wiki  technology  for 
collaboration  make  it  an  ideal  setting  for  maintaining  IA  policies  in  the  fast-paced  world 
of  cybersecurity.  In  a  world  where  constantly  evolving  technology  requires  frequent 
updates  to  IA  policy,  the  government  can  no  longer  afford  to  maintain  such  policies  in  a 
paper  or  Portable  Document  Format  (PDF)  due  to  the  exorbitant  amount  of  time  and 
effort  that  is  required  to  make  changes  to  it.  IA  policies  at  the  level  of  the  DON  may  be 
updated  frequently  with  the  advancement  of  technology.  The  lower-level  policies  that  are 
derived  from  the  DON-level  policies  for  use  in  an  implementation  setting  must  also  be 
updated  on  a  regular  basis.  It  is  at  the  implementation  level  that  policies  are  not  managed 
appropriately  due  to  difficulties  with  the  propagation  of  updates  to  policies  from  a  high- 
level  to  a  low-level.  If  IA  policies  are  not  current  at  the  implementation  level,  the  systems 
that  must  abide  by  the  policies  are  left  weak  and  vulnerable  to  attack.  When  policy 
updates  are  ignored  and  local-level  policies  are  neglected,  the  efficiency  of  government 
agencies  is  negatively  affected  in  a  way  that  could  potentially  compromise  national 
security.  At  the  very  least,  having  IA  policies  that  are  out-of-date  at  the  local  level  may 
have  legal  consequences  for  the  government  agency  that  is  responsible  for  maintaining 
them. 


C.  WIKI  TOOL  CHOICE 

Many  wiki  tools  are  available  that  would  work  for  the  maintenance  of  IA  policy, 
but  for  the  purposes  of  this  research  a  particular  wiki  was  chosen  for  a  proof  of  concept. 
The  Atlassian  Confluence  Wiki  provides  all  of  the  necessary  functionality  for  a  proof  of 
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concept  in  addition  to  being  the  wiki  of  choice  at  the  local-level  for  the  Naval 
Postgraduate  School.  Since  semantic  wikis  are  similar  in  tenns  of  the  functionality  that  is 
required  to  perform  the  proof  of  concept  for  this  research,  the  particular  wiki  that  is  used 
is  not  as  important  as  the  fact  that  the  policies  are  stored  and  maintained  on  a  wiki  site. 
When  the  wiki  is  configured  to  link  with  a  tool  to  track  issues  and  create  workflow  such 
as  Atlassian  JIRA,  it  can  perfonn  the  necessary  functions  to  not  only  house  policies,  but 
to  help  keep  them  up-to-date  as  well.  As  a  side-note,  JIRA  is  not  an  acronym.  This  is  just 
an  in-house  code  name  that  was  invented  by  the  Atlassian  JIRA  creators  [14].  Using  an 
issue-tracking  tool  such  as  JIRA  in  combination  with  the  wiki  allows  both  current  and  old 
versions  of  policies  to  be  housed  on  the  wiki  while  JIRA  functions  to  track  updates  and 
changes  to  policies.  This  combination  provides  the  structure  that  is  required  to  “push”  the 
conveyance  of  changes  to  upper-level  policies  down  to  administrators  of  the  lower-level 
policies  that  reference  them.  Any  wiki  and  issue-tracker  can  be  used  as  long  as  they 
integrate  in  an  effective  way  to  provide  the  following  functionality: 

1.  Requirements  of  an  Integrated  Wiki/Issue-Tracker  Tool 

The  important  functions  that  must  be  available  by  a  wiki  and  issue -tracker  tool  in 
order  to  implement  this  taxonomy  in  a  useful  way  are  as  follows: 

•  Users  must  be  able  to  subscribe  to  updates  with  a  given  frequency 

•  The  updates  that  a  user  is  made  aware  of  consist  of 

•  Changes  to  policies  including  those  that  are  added,  edited,  or 
deleted 

•  Comments  on  a  policy  that  are  added,  edited,  or  deleted 

•  The  notifications  can  be  customized  to  show  the  full  content  of  pages 
changed  as  well  as  the  differences  between  versions 

•  Minor  changes  (i.e.,  grammar  or  spelling  changes)  can  be  labeled  as  such 
so  they  do  not  cause  notifications  to  be  sent  out. 

•  Users  must  be  assigned  to  different  privilege  levels  to  allow  administrators 
the  ability  to  edit  content  and  other  users  the  ability  to  only  make  and  edit 
their  own  comments.  This  is  an  important  point  because  there  are  few 
people  who  are  allowed  to  make  changes  to  the  content  of  IA  policy. 
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•  Notifications  can  be  customized  to  alert  the  administrator  to  changes 
within  particular  groups  of  policies  so  that  the  policies  that  must  be 
reviewed  are  clearly  identified. 

D.  POLICY  HIERARCHY  AND  TAXONOMY 

Before  the  policies  can  be  linked  in  the  wiki,  they  must  be  ordered  hierarchically 
in  a  taxonomy.  Providing  this  framework  at  the  outset  before  policies  are  placed  on  the 
wiki  is  the  most  efficient  way  to  ensure  that  policies  are  linked  correctly  and  that  updates 

will  be  propagated  accurately.  The  idea  is  for  the  wiki  to  manage  the  work  to  maintain  IA 

policies  and  to  enable  the  administrator  to  determine  at  a  glance  which  lower-level 
policies  are  affected  by  changes  to  upper-level  policies. 

E.  WHERE  POLICIES  ARE  STORED  ONLINE 

A  detail  that  cannot  be  determined  by  this  thesis  is  where  to  house  the  upper- 
bound  policies  since  this  decision  lies  with  the  DON.  Typically,  IA  policies  at  the  DoD- 
level  are  hosted  on  websites  such  as  the  National  Institute  of  Standards  and  Technology 
website  and  Defense  Technical  Infonnation  Center  website,  while  DON-level  policies  are 
hosted  on  websites  such  as  the  Department  of  the  Navy  Chief  Information  Officer 
website  and  the  Department  of  the  Navy  Issuances  website.  It  is  beyond  the  scope  of  this 
thesis  to  dictate  where  IA  policies  are  stored,  but  this  will  be  one  of  the  topics  discussed 
in  the  Future  Works  section.  To  solve  the  problem  of  referencing  IA  policies  in  the 
upper-bound  within  the  wiki  structure,  the  text  of  the  most  current  policy  will  be  copied 
and  pasted  into  the  wiki.  Administrators  will  have  to  subscribe  to  RSS  feeds  and  email 
lists  to  leam  when  DON-level  policies  are  updated,  which  is  the  current  practice  for 
staying  up-to-date  on  DON-level  policies.  The  DON  Issuances  website  already  provides  a 
useful  taxonomy  and  version  system  to  indicate  which  policies  are  in  use  and  which  are 
out-of-date.  As  updates  occur,  the  administrator  can  “version”  old  policies  so  they  will 
continue  to  be  accessible  on  the  wiki,  but  there  will  be  no  mistake  as  to  which  version  is 
the  most  current.  As  changes  are  made,  the  administrator  will  be  notified  of  all  of  the 
policies  that  must  be  reviewed  based  on  the  linking  structure  of  the  policies  within  JIRA. 
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Given  the  implementation  of  the  taxonomy  in  the  wiki,  the  updates  will  be  conveyed 
accurately  to  ensure  that  policies  do  not  go  out-of-date  as  a  result  of  neglect. 
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III.  TAXONOMY  FRAMEWORK 


A.  CHOICES  FOR  TAXONOMY 

The  taxonomy  that  is  used  to  determine  how  policies  updates  are  pushed  down  to 
the  local  level  from  the  DON  level  is  distinct  from  the  NPS  Policy  Hierarchy  as  described 
in  Figure  1 .  Although  the  figure  is  straightforward  in  tenns  of  describing  the  relationship 
between  policies  that  exist  in  a  simple  tree  structure,  it  does  not  address  the  difficulties  of 
representing  the  flow  of  information  between  policies  when  the  structure  is  more 
complicated,  as  is  often  the  case  within  the  government.  The  basic  structure  of  linking 
policies  from  the  upper  level  to  the  lower  level  is  based  on  the  one  represented  in 
Figure  1,  but  the  difference  comes  in  the  case  that  policies  reference  one  another  at  the 
same  level,  or  where  multiple  upper-level  policies  are  referenced  by  a  single  lower-level 
policy.  In  order  for  the  taxonomy  for  this  research  to  be  expanded  from  the  hierarchy  in 
Figure  1,  some  choices  must  be  made.  When  policies  are  arranged  in  a  hierarchy,  they 
can  either  be  grouped  by  the  policies  from  which  they  are  derived  (Figure  2),  or  by  the 
policies  that  are  derived  (Figure  3).  The  models  that  were  considered  to  represent  how 
policy  hierarchy  should  be  implemented  at  the  local-level  are  described  as  follows: 

1.  Group  by  Upper-Bound  vs.  Lower-Bound  Policies 

When  policies  are  grouped  by  the  DON-level  policies  from  which  they  were 
derived,  the  importance  is  placed  on  the  upper-level  policies.  This  model  seems  more 
intuitive,  but  the  strengths  and  weaknesses  of  both  models  had  to  be  examined  separately 
to  make  a  decision  on  which  should  be  used  in  the  context  of  this  research.  The  concept 
of  a  tree-style  hierarchy  and  the  resulting  groups  was  derived  from  an  example  semantic 
partition  tree  of  the  New  York  Times  front  page  [15],  While  the  application  of  a  semantic 
partition  in  that  case  was  used  to  discover  the  implicit  schema  for  the  hierarchical 
relationships  between  concepts,  its  usefulness  can  be  expanded  to  the  domain  of  IA 
policy  hierarchy.  In  the  top-down  model,  the  highest-level  policy  is  examined  for 
changes,  and  the  changes  flow  downstream  to  the  lower-level  policies.  This  is  the  same  in 
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both  models,  but  the  difference  lies  in  the  grouping  of  the  policies.  When  policies  are 
grouped  by  upper-bound,  a  lower-level  policy  may  reside  in  the  groups  of  multiple  upper- 
level  policies.  On  the  other  hand,  when  policies  are  grouped  by  lower-bound,  each  lower- 
level  policy  resides  in  its  own  group,  and  multiple  upper-bound  policies  may  reside  in  the 
same  group  as  the  lower-bound  policy  without  having  their  own  group.  This  second 
configuration  of  grouping  by  the  lower-level  policies  places  the  emphasis  on  the  lower- 
level  policies  that  must  be  updated  at  the  implementation  level.  The  difference  between 
the  two  models  is  illustrated  by  Figure  2  and  Figure  3.  The  grouping  of  policies  given  in 
Figure  2  shows  the  simplicity  of  grouping  by  the  upper-bound.  In  Figure  3,  the  grouping 
of  policies  by  lower-bound  gets  complicated  very  quickly.  This  is  due  to  the  fact  that 
policies  go  from  more  general  at  the  upper-bound  to  more  specific  at  the  lower-bound. 
This  causes  fewer  upper-bound  policies  to  branch  into  a  much  greater  number  of  lower- 
bound  policies. 


NPS  Policy  Hierarchy 


Figure  1.  NPS  Policy  Hierarchy.  From  [16]. 
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Figure  2.  Group  by  Upper-bound 


Figure  3.  Group  by  Lower-bound 


In  the  end,  it  was  simpler  and  more  effective  to  group  by  upper-bound  policies 
because  this  was  the  easiest  way  to  convey  the  correct  flow  of  information  from  top-to- 
bottom.  The  lower-bound  grouping  requires  the  administrator  to  look  at  a  lower-level 
policy  when  it  is  time  for  an  update  and  determine  which  changes  have  been  made  to 
upper-level  policies.  This  grouping  of  policies  may  cause  multiple  upper-level  policies  to 
be  examined  even  when  no  changes  were  made  to  a  particular  upper-level  policy.  This 
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allows  all  of  the  policy  changes  for  the  local  policy  to  be  done  at  once,  but  it  is  time- 
consuming  in  that  it  requires  the  administrator  to  examine  all  policies  to  detennine  where 
changes  have  occurred.  In  the  top-down  grouping,  the  administrator  examines  all  policies 
downstream  of  the  upper-level  policy  that  was  changed,  and  makes  changes  accordingly. 
In  this  model,  a  lower-level  policy  that  references  multiple  upper-level  policies  that  have 
changed  will  be  examined  multiple  times.  In  spite  of  this,  it  is  still  more  efficient  to 
examine  a  lower-level  policy  multiple  times  in  the  event  of  updates  to  multiple  upper- 
level  policies  than  it  is  to  examine  upper-level  policies  even  when  they  have  not  changed. 

B.  TAXONOMY  OUTLINE 

1.  NPS  Policy  Hierarchy 

The  hierarchy  begins  with  the  policies  at  the  DON  level  and  works  down  to  the 
local  NPS  level.  The  directionality  for  this  hierarchy  causes  many  of  the  groups  to 
overlap  to  a  certain  extent.  This  overlap  can  be  defined  in  such  a  way  that  the  upper-level 
policy  changes  do  not  cause  notifications  to  be  created  for  the  other  upper-level  policies. 
The  notifications  will  only  be  created  for  the  policies  at  levels  that  the  administrator  can 
modify.  The  hierarchy  described  in  this  way  makes  the  clearest  structure  for  the  purposes 
of  linking  the  policies  in  the  wiki.  The  hierarchy  that  is  implemented  in  the  wiki  is 
illustrated  in  Figure  4. 


Figure  4.  Policy  Taxonomy 
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2. 


Flow  of  Information 


The  hierarchy  of  IA  policies  in  the  DoD  begins  with  the  law  at  the  top  level,  then 
the  Executive  Branch,  the  DoD  level,  the  Joint  Command,  Service,  and  Agency  level, 
then  NPS  Instructions  and  policy,  and  from  there  down  to  the  level  of  Standards, 
Baselines,  Guidelines,  and  Procedures  at  the  local  NPS  level  (Figure  1).  The  section  of 
this  hierarchy  that  will  be  examined  is  the  DON  for  the  upper-bound  and  the  NPS  local 
policies  for  the  lower-bound.  Multiple  ways  of  grouping  the  policies  were  considered  in 
this  research  with  the  focus  placed  on  how  to  get  the  most  efficient  linking  between 
policies.  The  efficiency  of  the  linking  is  detennined  by  how  well  the  updates  from  upper- 
level  policies  are  propagated  to  the  lower-level  policies.  There  are  complex  relationships 
between  policies  because  they  are  often  intertwined  in  ways  that  make  it  difficult  to 
represent  them  in  a  graphical  format.  A  given  upper-level  policy  may  link  to  many  lower- 
level  policies;  a  single  lower-level  policy  may  link  to  multiple  upper-level  policies; 
lower-level  policies  may  link  to  each  other.  With  all  of  this  linking,  the  policies  form  a 
sort  of  web  as  opposed  to  a  simple  graph  or  flow  diagram.  Some  of  the  updates  that  occur 
to  upper-level  policies  may  require  updates  to  the  lower-level  policies  that  reference 
them,  but  some  do  not.  Likewise,  some  of  the  updates  to  lower-level  policies  will  require 
updates  to  other  lower-level  policies  that  reference  them,  but  this  is  not  necessarily  the 
case.  This  taxonomy  is  necessary  to  describe  the  relationships  between  all  IA  policies 
from  the  upper-level  to  the  lower-level,  and  between  policies  on  the  same  level.  The 
upper-level  policies  will  not  change  as  a  result  of  changes  to  other  policies  in  order  to 
satisfy  the  requirement  that  updates  flow  only  from  upper-level  to  lower-level,  and 
between  policies  at  the  same  level  where  the  relationship  exists.  The  flow  of  updates 
between  policies  on  the  same  level  is  allowed  where  necessary.  This  relationship  usually 
occurs  at  the  local-level. 

3.  Description  of  Taxonomy  Identifiers 

Since  updates  are  accurately  propagated  within  the  wiki  when  this  implementation 
of  the  taxonomy  is  used,  the  policies  can  be  grouped  as  illustrated  in  Figure  2  with  top- 
down  infonnation  flow.  The  groups  are  defined  by  the  upper-level  policies  in  this 
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example  as  follows:  policies  on  the  level  of  the  upper-bound  can  be  identified  as  DON-A, 
DON-B,  and  DON-C.  The  next  level  of  policies  that  reference  the  policies  on  the  upper- 
bound  are  identified  as  NAVPGSCOLINST.  These  are  NPS  instructions  and  for  the  sake 
of  brevity  will  be  referred  to  as  “NPS  Inst”  and  further  distinguished  by  a  letter  and 
number  as  follows:  NPS  Inst-Al,  NPS  Inst-A2,  NPS  Inst-Bl,  and  NPS  Inst-Cl.  This  is 
done  to  show  that  the  NPS  instruction  came  from  a  particular  DON  policy.  In  the  small 
example  given  for  demonstration  purposes  in  this  research,  the  letter  that  is  assigned  to 
the  NPS  instruction  is  assigned  based  on  the  DON  policy  that  it  references  most  or  first, 
and  the  number  differentiates  between  multiple  NPS  instructions  that  reference  the  same 
DON  policy.  In  actual  implementation  of  this  model,  the  numbers  and  letters  that  are 
assigned  may  correspond  with  the  DON  level  series  number  to  unambiguously  indicate 
the  relationships  between  policies.  From  the  DON  Issuances  website,  the  current 
taxonomy  for  DON-level  policies  utilizes  the  Standard  Subject  Identification  Code 
(SSIC)  and  is  described  as,  “the  standard  system  of  numbers  and  letter  symbols  used 
throughout  the  Department  of  the  Navy  for  categorizing  departmental  records  by  subject. 
SSICs  serve  as  the  taxonomy  for  all  departmental  records,”  [17].  The  next  level  down  is 
the  “local”  NPS  level,  and  this  is  the  lower-bound  of  this  research.  This  level  represents 
the  policies,  guidelines,  standards,  and  procedures  that  reside  at  the  local  implementation 
level.  In  the  given  example,  these  lower-level  policies  are  labeled  as  LLP  followed  by  a 
letter  to  signify  the  DON  instruction  they  reference  and  a  number  to  differentiate  between 
them,  much  the  same  way  the  policies  do  at  the  level  directly  above  this  level.  For 
example,  Figure  4  lists  the  local  policies  as  follows:  LLP-A1,  LLP-A2,  LLP-A3,  LLP- 
Bl,  LLP-B2,  and  LLP-C1. 

4.  Policy  References 

The  flow  of  infonnation  between  policies  is  represented  by  the  directional  arrows 
represented  in  Figure  4.  The  arrows  show  that  the  information  from  the  DON-level 
policies  at  the  upper-bound  flow  to  the  NPS  instructions  at  the  next  level,  and  from  there 
to  the  NPS  local  policies  at  the  lower-bound.  The  language  used  to  describe  a  relationship 
where  an  upper-level  policy  has  an  arrow  pointing  to  a  lower-level  policy  is  that  the 
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upper-level  policy  is  referenced  by  the  lower-level  policy  and  the  lower-level  policy 
references  the  upper-level  policy.  This  distinction  in  language  is  an  important  one  to 
make  as  this  is  the  relationship  that  allows  JIRA  to  define  the  flow  of  information 
between  policies.  Policies  at  the  same  level  such  as  LLP-B2  and  LLP-C1  can  also  be 
defined  by  this  relationship  as  follows:  LLP-B2  is  referenced  by  LLP-C1  and  LLP-C1 
references  LLP-B2.  This  shows  that  the  information  flows  from  LLP-B2  to  LLP-C1. 
Another  view  of  the  hierarchy  is  shown  by  the  tree  diagram  in  Figure  5. 

View:  Recently  Updated  -  Alphabetical  •  Tree 

s  0j  Swisher  Thesis  Home  A 
0)  Policy  Hierarchy 
s  [3]  Policy  Flowchart 
a  g)  DoN-A 

a  0|  NPS  Instruction  A1 

0|  Lower  Level  Policy  A1 
01  Lower  Level  Policy  A2 
a  0)  NPS  Instruction  A2 

0|  Lower  Level  Policy  A3 
a  01  DoN-B 

a  0)  NPS  Instruction  B1 

0)  Lower  Level  Policy  B1 
@1  Lower  Level  Policy  B2 
a  0)  DoN-C 

a  0)  NPS  Instruction  Cl 

0)  Lower  Level  Policy  Cl 


Figure  5.  Policy  Flierarchy  Tree  in  the  Wiki 

5.  Redundancies  in  Information  Flow 

In  this  model,  it  is  necessary  for  lower-level  policies  to  be  able  to  reference  one 

another.  In  this  instance,  this  model  for  linking  policies  may  cause  some  redundancies  as 

the  lower-level  policies  may  be  updated  multiple  times.  This  is  a  result  of  the  automatic 

propagation  of  notifications  as  policies  are  updated.  All  of  the  notifications  will  go  out  as 

described  by  this  path  only  if  changes  are  actually  made  to  the  policies  that  are 

referenced  by  the  other  policies.  Without  a  change  to  set  off  a  notification,  the  subsequent 
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policies  in  the  path  will  not  be  affected.  The  notifications  stop  when  the  administrator 
stops  making  changes.  Since  this  taxonomy  is  only  necessary  for  the  administrator  to  be 
alerted  to  changes,  there  is  still  a  human-level  check  to  determine  whether  an  update  to 
the  affected  policy  is  required.  This  check  prevents  infinite  loops  in  the  case  of  two 
policies  referencing  each  other  and  renders  circular  referencing  harmless. 
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IV.  IMPLEMENTATION 


A.  OVERVIEW 

This  research  takes  the  previously  described  taxonomy  and  implements  it  in  the 
context  of  a  wiki  combined  with  an  issue  tracker.  There  is  no  particular  tool  that  is 
intended  to  be  promoted  by  this  research.  The  tool  that  was  chosen  serves  the  purpose  of 
this  research.  Any  wiki  technology  and  issue  tracker  that  work  in  combination  with  each 
other  are  appropriate  if  they  have  the  required  functionality  as  outlined  in  section  II  of 
this  thesis.  For  the  purposes  of  this  thesis,  the  chosen  tools  are  the  Atlassian  Confluence 
Wiki  in  conjunction  with  the  Atlassian  Confluence  JIRA.  The  Atlassian  Confluence  Wiki 
(hereafter,  referred  to  as  wiki)  is  a  semantic  wiki  collaboration  tool  that  can  be  used  by 
small  groups  or  large  agencies  for  sharing  infonnation  [18].  The  Atlassian  Confluence 
JIRA  (hereafter  referred  to  as  JIRA)  works  as  a  collaborative  project  tracking  tool  that  is 
good  for  teams  [14].  This  choice  was  made  based  on  availability  and  capabilities  of  the 
tools,  but  anything  with  the  right  functionality  will  do. 

Using  the  wiki  to  house  policies  in  this  way  enables  the  policy  changes  from  the 
upper-level  to  the  lower-level  to  be  conveyed  automatically.  In  order  to  implement  this 
structure  in  the  wiki  it  is  necessary  to  perform  a  certain  amount  of  front-end  work  to 
upload  current  policies  into  the  wiki  and  create  linked  issues  for  all  of  the  policies  using 
JIRA.  Once  the  policies  have  been  uploaded  and  linked  according  to  this  taxonomy,  it 
becomes  a  simple  matter  to  maintain  the  policies  so  they  do  not  go  out  of  date.  The 
amount  of  front-end  work  that  is  required  to  begin  this  process  mitigates  the  amount  of 
long-term  work  that  it  takes  to  manually  search  and  update  policies  as  they  go  out  of  date. 
The  extensive  amount  of  work  and  research  that  is  currently  necessary  for  administrators 
to  perfonn  these  duties  is  greatly  lessened  by  the  policy  management  described  by  this 
research. 
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B. 


UPPER-BOUND 


The  upper-bound  policies  that  are  detailed  by  the  small  example  given  in  Figure  4 
are  DON-A,  DON-B,  and  DON-C.  These  policies  are  housed  in  the  wiki  and  NPS 
instructions  are  added  as  child  pages  to  the  appropriate  DON-level  policies  in  the  wiki. 
These  policies  have  JIRA  issues  created  for  them  as  well.  This  continues  until  all  of  the 
policies  have  been  added  to  the  wiki  and  JIRA  issues  have  been  created  for  each  policy 
(Figure  6).  The  policies  should  be  added  as  child  pages  such  that  the  higher-level  policies 
are  parent  pages  of  the  lower-level  policies.  This  is  achieved  by  adding  lower-level 
policies  to  the  upper-level  policies  as  child  pages,  creating  a  tree  hierarchy  (Figure  5). 
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Figure  6.  Atlassian  JIRA  Issues  Page 


C.  LOWER-BOUND 

In  the  instance  that  there  is  a  child  policy  that  references  multiple  upper-level 
policies,  the  lower-level  policy  will  be  added  as  a  child  page  to  the  upper-level  policy  that 
it  is  named  after.  The  naming  scheme  as  defined  in  Section  III  describes  this  naming 
convention  and  makes  the  decision  of  where  to  store  policies  on  the  wiki  unambiguous. 
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D.  GROUPING  OF  POLICIES 

The  policies  are  labeled  both  on  the  wiki  and  on  the  JIRA  site  with  all  of  the 
policies  within  their  group.  If  information  can  flow  between  policies,  they  are  given  each 
other’s  labels  so  that  a  simple  lookup  of  each  label  shows  all  other  policies  within  that 
group.  For  example,  the  DON-B  policy  has  the  following  labels:  donb,  npsinstbl,  llpbl, 
and  llpb2  which  represent  all  of  the  policies  that  may  be  affected  by  changes  to  the  DON- 
B  policy  (Figure  7).  All  of  the  other  policies  within  this  group  also  have  at  least  these 
labels.  In  the  case  of  the  NPS  Inst-Bl,  it  references  both  DON-B  and  DON-C,  so  it 
carries  an  additional  label  (Figure  8).  Likewise,  the  LLP-B1  policy  carries  the  labels  for 
DON-A,  NPS  Inst-A2,  and  DON-C  in  addition  to  the  other  labels  that  DON-B  carries 
(Figure  9). 
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E.  LINKING  AND  FLOW  OF  POLICY  UPDATES 

It  is  important  to  note  that  the  lower-level  policies  in  the  previous  example  have 
labels  across  groups  for  multiple  upper-level  policies,  but  the  upper-level  policies 
themselves  remain  free  of  these  extra  labels.  This  is  because  infonnation  flow  from 
lower-level  policies  to  upper-level  policies  is  not  allowed.  The  labels  are  not  the  only 
way  to  determine  which  policies  should  be  updated  based  on  changes  to  upper-level 
policies,  however.  The  integration  of  the  issue-tracker  with  the  wiki  is  essential  for  the 
successful  propagation  of  policy  updates  from  upper-level  policies  to  lower-level 
policies. 

The  capability  of  linking  issues  within  JIRA  allows  policies  to  refer  to  each  other 
in  such  a  way  that  the  flow  of  policy  updates  is  obvious  to  users  of  this  tool.  In  this 
example,  the  DON-level  policies  will  link  directly  with  the  NPS  instructions,  and  the 
instructions  will  link  to  the  policies  on  the  lower-  level.  This  linking  occurs  within  JIRA 
by  assigning  the  policy  at  the  upper-level  as  referenced  by  the  policy  at  the  lower-level, 
and  the  policy  at  the  lower-level  as  refers  to  the  policy  at  the  upper-level  (Figures  7,  8,  9). 
Policies  at  the  same  level  may  reference  each  other  the  same  way  with  either  a 
symmetrical  or  an  asymmetrical  relationship  based  on  the  hierarchy  that  is  defined. 

Since  each  policy  housed  in  the  wiki  has  a  corresponding  issue,  and  issues  are 
linked  as  described  above,  the  flow  of  policy  information  is  well-defined.  As  a  DON- 
level  policy  is  updated,  the  administrator  adjusts  the  corresponding  issue  in  JIRA  to 
reflect  the  status  of  the  policy  update  (i.e.,  open,  in  progress,  resolved,  closed). 

F.  NOTIFICATIONS 

When  a  change  is  made  to  a  policy  on  the  wiki  or  to  an  issue  in  JIRA,  email 
notifications  of  the  change  are  sent  out  as  prescribed  by  the  administrator.  In  this 
example,  the  administrator  may  subscribe  to  email  notifications  of  changes  that  are  made 
to  policies  within  the  wiki  with  the  notification  settings  to  include  the  changes  within  the 
email  itself.  This  means  that  when  a  policy  is  updated,  the  administrator  can  receive  an 
email  notification  that  a  change  has  happened,  and  the  changes  may  be  included  within 
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the  email.  The  email  lists  stay  current  automatically  because  the  admin  can  select  the 
option  to  receive  emails  regarding  any  issue  they  create,  or  “mention”  someone  else  to 
cause  another  user  to  receive  emails  regarding  that  issue.  When  the  issue  that  corresponds 
to  a  particular  policy  is  updated  in  JIRA,  the  administrator  is  notified  of  this  as  well.  All 
of  the  linked  issues  that  are  associated  with  the  issue  for  a  particular  policy  that  is 
changed  within  JIRA  can  be  set  to  re-open  if  they  were  closed,  and  the  workflow 
property  in  JIRA  also  allows  due  dates  to  be  set  for  the  tasks  that  are  assigned.  For 
example,  if  a  DON-level  policy  is  updated,  the  administrator  will  receive  an  email 
notification  from  the  wiki  of  the  change.  The  administrator  goes  to  the  wiki  policy  page 
and  updates  the  JIRA  issue  to  “Open.”  A  notification  of  the  workflow  change  in  JIRA  is 
sent  out.  The  administrator  then  goes  to  JIRA  where  all  of  the  links  to  and  from  the 
changed  policy  are  visible  and  tasks  are  assigned  for  affected  policies  to  be  reviewed. 
From  there,  it  is  a  simple  matter  of  completing  the  tasks  assigned  by  JIRA  to  update  the 
necessary  policies.  An  example  workflow  diagram  from  JIRA  is  shown  in  Figure  10.  The 
workflow  can  be  customized  to  reflect  the  stage  of  progress  that  a  policy  is  in.  For 
example,  if  the  workflow  is  altered  to  define  a  new  state  that  indicates  when  a  policy  is  in 
the  update  phase,  this  state  is  visible  to  everyone  with  the  required  permissions. 
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Figure  10.  JIRA  Issue  Workflow 
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V.  ANALYSIS  AND  CONCLUSION 


The  taxonomy  presented  in  this  thesis  is  built  upon  the  existing  policy  hierarchy 
as  illustrated  in  Figure  1.  The  main  difference  stems  from  the  choice  that  must  be  made  in 
tenns  of  the  flow  of  information  between  policies  when  the  linking  between  policies 
becomes  complicated.  The  original  policy  hierarchy  does  not  address  the  problem  of  how 
to  group  policies  when  information  flows  from  multiple  upper-level  policies  to  multiple 
lower-level  policies,  and  when  lower-level  policies  reference  each  other.  This  has  been  a 
significant  barrier  for  using  wiki  technology  to  link  policies  and  have  updates  propagated 
from  top  to  bottom  in  the  IA  policy  domain.  So  far,  each  government  agency  deals  with 
this  problem  as  they  see  fit.  This  means  that  even  though  IA  policies  have  been  migrated 
to  an  online  domain  at  the  top  (DON)  levels,  the  lower-levels  where  implementation  of 
these  policies  is  performed  suffer  without  the  infrastructure  to  continue  the  chain  of 
policy  updates. 

The  weak  link  in  IA  policy  maintenance  lies  within  the  implementation  level, 
since  many  agencies  continue  to  deal  with  PDF  or  paper  versions  of  policies.  In  this  day 
and  age,  there  is  no  reason  to  resist  the  movement  of  IA  policy  maintenance  to  online 
collaborative  environment,  such  as  a  wiki.  Many  government  agencies  have  taken  the 
first  steps  to  moving  their  IA  policies  online,  but  with  no  clear  workflow  to  keep  them 
updated,  they  are  still  sifting  through  the  same  manual  process  that  has  plagued  the 
government  since  the  times  of  hard-copy  policy  maintenance.  This  research  presents  the 
infrastructure  necessary  to  finally  link  policies  and  provide  automatic  conveyance  of 
policy  updates  in  a  timely  and  cost-effective  manner. 

Given  the  amount  of  time  and  resources  that  must  be  spent  on  policy 
maintenance,  the  ideas  described  in  this  research  present  cost-effective  solutions  that 
require  moderate  up-front  work  to  implement,  and  minimal  effort  to  maintain.  In  addition 
to  this,  versions  of  IA  policies  remain  available  and  are  distinguished  by  version  numbers 
that  give  a  clear  indication  of  which  policy  is  the  current  one  without  denying  access  to 
older  policy  versions.  This  is  a  vast  improvement  over  the  current  practice  within 
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government  agencies,  and  the  benefits  are  not  limited  to  the  IA  policy  family.  This 
structure  gives  the  foundation  for  policy  maintenance  that  can  easily  be  extended  to  any 
class  of  policy  that  exists  in  a  hierarchy.  The  impact  of  the  practices  outlined  by  this 
research  is  far-reaching,  and  if  this  approach  is  tailored  to  deal  with  other  hierarchical 
updating  schemes,  the  efficiency  of  policy  maintenance  will  dramatically  improve. 
Having  policies  that  are  up-to-date  is  essential  to  the  daily  functioning  of  any 
organization. 
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VI.  FUTURE  WORK 


A.  POLICY  WIKI  WITHIN  U.  S.  GOVERNMENT 

This  research  has  addressed  the  problem  of  IA  policy  maintenance  at  the 
implementation  level  of  the  government,  but  there  is  potential  for  this  type  of 
collaboration  at  every  level  within  the  government.  The  link  that  is  weakest  at  the 
moment  is  the  implementation  level  of  policy  maintenance.  As  this  is  dealt  with,  the  next 
step  is  to  have  wiki  collaboration  at  the  DON  level  on  all  policies,  just  as  Intellipedia  is  a 
wiki  for  government  intelligence.  From  there,  it  is  conceivable  that  this  model  be 
implemented  at  the  DoD-level  to  ensure  compliance  with  and  maintenance  of  policies 
government-wide. 

In  the  immediate  future,  this  research  will  be  applied  at  NPS  by  the  Infonnation 
Technology  and  Communications  Services  (ITACS)  department.  This  will  ensure  that 
NPS  maintains  the  readiness  of  our  defense  technologies  and  systems,  and  continues  to 
enhance  national  security  by  maintaining  current  IA  policies. 

Further  work  is  required  to  determine  a  suitable  hierarchy  across  the  government 
for  all  policies  to  be  housed  on  the  same  or  compatible  wiki  environments  to  allow 
smooth  policy  updates  to  be  pushed  from  the  top  level  to  the  lower  levels.  The  focus  of 
most  policy  work  within  the  government  has  been  at  the  DON  level  and  above,  but  when 
policy  requirements  are  ultimately  executed  at  the  implementation  level,  broken  lines  of 
communication  can  have  a  devastating  effect  on  the  operational  readiness  of  our  forces. 
This  is  an  important  focus  of  future  research  and  development. 
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